From wang!elf.wang.com!ucsd.edu! packet-radio-relay Thu Jan 31 16:13:58 1991 remote 
from tosspot 
Received: by tosspot (1.63/waf) 
via UUCP; Thu, 31 Jan 91 21:31:51 EST 
for lee 
Received: from somewhere by elf.wang.com 
id aai5335; Thu, 31 Jan 91 16:13:53 GMT 
Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP 
id AAQ2805; Thu, 31 Jan 91 09:39:02 -0500 
Received: by ucsd.edu; id AA02236 
sendmail 5.64/UCSD-2.1-sun 
Thu, 31 Jan 91 04:30:30 -0800 for hpbbrd!dbOsao!dg4scv 
Received: by ucsd.edu; id AAQ2220 
sendmail 5.64/UCSD-2.1-sun 
Thu, 31 Jan 91 04:30:12 -0800 for /usr/lib/sendmail -oc -odb -o0Q/var/spool/ 
lqueue -oi -fpacket-radio-relay packet-radio-list 
Message-Id: <9101311230.AAQ2220@ucsd.edu> 
Date: Thu, 31 Jan 91 04:30:06 PST 
From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu> 
Reply-To: Packet-Radio@ucsd.edu 
Subject: Packet-Radio Digest V91 #30 
To: packet-radio@ucsd.edu 


Packet-Radio Digest Thu, 31 Jan 91 Volume 91 : Issue 30 


Today's Topics: 
2 DRSI Boards and NET/NOS? 
<None> 
Help! What is it? (2 msgs) 
Need 56 Kbps info from .ba folks 
Omni vs Beam? 

Omni vs beam antennas. (4 msgs) 
PACKET->Internet Gateway 
Piccolo info. 

Problem with NET and another TSR 
Procomm Bug in Packet Use 
Shareware on Packet 
TCP/IP over long distances 
Trolling for suggestions 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 17 Jan 91 20:39:07 GMT 

From: pacbell.com!tandem!Tandem.COM!stu@ucsd.edu (Stuart Phillips) 
Subject: 2 DRSI Boards and NET/NOS? 

To: packet-radio@ucsd.edu 


In article <958400001@techsup>, kenb@techsup.UUCP writes: 
|> 


|> a local ham, no newsgroup access, is trying to run nos with 2 
|> DRSIT boards. he has the following: 


|> drsi pcpa type 2 @ 300h 
|> drsi pcpa type 1 @ 310h 


|> 

|> both use int 7 (not sure if this is selectable on the board -- i 
|> don't own drsi boards) 

|> 

STUFF DELETED 

|> ... isit possible to use 2 drsi 


|> boards with net or nos? if so, what version of net/nos? also, 
|> i'd appreciate a sample set of attach commands for each board to 
|> pass along. 


The DRSI driver will only support one card; its not too difficult to change 
but (as the author of the driver) I don't intend to make the change. You 
would be well advised to have separate interrupts for each board. 


You should be able to configure the scc driver to handle two boards but 
you will need two interrupts. Unfortunately I dont have any example of 
how this would be configured. 


The interrupt is switch selectable on the board. 


Good luck ! 
Stu N6TTO 


Date: 17 Jan 91 20:34:34 GMT 

From: att!pacbell.com!tandem! Tandem.COM!stu@ucbvax.Berkeley.EDU (Stuart Phillips) 
Subject: <None> 

To: packet-radio@ucsd.edu 


In article <860@idacrd.UUCP> mac@idacrd.UUCP (Robert McGwier) writes: 
>Howdy : 

> 

>Is there anyone on this net that can answer from first hand knowledge 
>whether or not DRSI has closed its doors? 

> 


I saw an earlier posting asking the same question and so phoned DRSI this 
morning. Andy DeMartini assured me that he and his company were very much 
still in the land of the living and doing well. Seems I was the third person 
to call and ask. 


DRSI are 100% still in business - Mr D. is interested in discovering the 
source of the rumor ! 


Stuart N6TTO 


Date: 29 Jan 91 21:57:45 GMT 

From: pacbell.com!tandem! tandem! kevinr@ucsd.edu (Kevin J. Rowett) 
Subject: Help! What is it? 

To: packet-radio@ucsd.edu 


In article <andreap.665077581@s.ms.uky.edu>, andreap@ms.uky.edu (Peach) writes: 
|> I have discovered a packet radio signal, locally, on 412.875 MHz. 

|> While it is not in the ham band, it sounds very similar to 1200 

|> baud packet. 


More than likely it is your local police department using AR packet 
technology (DRSI may very have well sold it to them, Sunnyvale, CA 

bought theirs from DRSI). The modem frequencies aren't the same 

to keep the obviously uneducated out, but it's not even encrypted. 


N6RCE 


Date: 30 Jan 91 16:17:56 GMT 

From: sun-barr!cs.utexas.edu!evax!utacfd!letni!rwsys! kf5iw! k5qwb! 1rk@apple.com 
(Lyn R. Kennedy) 

Subject: Help! What is it? 

To: packet-radio@ucsd.edu 


andreap@ms.uky.edu (Peach) writes: 


> I have discovered a packet radio signal, locally, on 412.875 MHz. 
> While it is not in the ham band, it sounds very similar to 1200 


> baud packet. 

> 

Most likely this is a wind shear system at your local airport. 
Signal strength should confirm that. 

It's probably not anything similar to ax.25 but I have not examined 
one, however I've never found x.25 signals in this band. 


1rk 


Date: 30 Jan 91 01:43:27 GMT 

From: hpl-opus!hpnmdla!hpsadle!mikef@hplabs.hpl.hp.com (Mike Ferrara) 
Subject: Need 56 Kbps info from .ba folks 

To: packet-radio@ucsd.edu 


We're working on a 2Mb/s one here. Expect the first hardware to 
be running late '91. We'll be using either 3400QMHz or 5700 MHz. 


Mike Ferrara M/S 2LRR 

HP Signal Analysis Div R&D 

1212 Valley House Drive 

Rohnert Park, CA 94928 

(707) 794-4479 
mikef%hpsadle@hp-sde.sde.hp.com 
mikef@hpsadle.hp.com 


Date: Wed, 30 Jan 91 15:03:05 GMT 

From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <PJML@ibma.nerc- 
wallingford.ac.uk> 

Subject: Omni vs Beam? 

To: PACKET-RADIO@ucsd.edu 


To all of you who have entered the above discussion... 
Thanks! you've just earned me a beer!! 


Pete Lucas PJML@UK.AC.NWL.TA G6WBJ@GB7SDN.GBR.EU 


Date: Wed, 30 Jan 91 11:45:18 EST 

From: barry@dgbt.doc.ca (Barry McLarnon DGBT/DIP) 
Subject: Omni vs beam antennas. 

To: packet-radio@ucsd.edu 


One situation in which I think it makes sense to use directional antennas 
is a CSMA LAN with a full-duplex repeater. The repeater typically has a 
central location and uses an omni antenna (or separate omni receive and 
transmit antennas). If the users have directional antennas aimed at the 
repeater site, there are several benefits: they are less likely to have 
interference (from out-of-band sources causing intermod, or in-band sources 
that the repeater can't hear), they radiate less energy away from the 
intended coverage area, and the higher link margins allow the repeater ERP 
and/or antenna heights to be reduced. In essence, the gain antennas help 
to define a "tighter" coverage area for the LAN, so the frequencies can 

be re-used with less geographical spacing. Of course, users near the 
repeater can use omni antennas if they wish - it's more important for the 
users on the fringes to use gain antennas, so as not to extend the 
coverage (in terms of susceptibility and interference-causing potential) 
of the LAN beyond that defined by the repeater itself. 


Barry 

| Barry McLarnon Communications Research Center, Ottawa, ON, Canada | 
| Internet: barry@dgbt.doc.ca 

| Packet BBS: VE3JF@VE3IF AMPRnet: barry@bbs.ve3jf [44.135.96.6] | 


Date: 29 Jan 91 17:54:41 GMT 

From: hpl-opus!hpnmdla!glenne@hplabs.hpl.hp.com (Glenn Elmore) 
Subject: Omni vs beam antennas. 

To: packet-radio@ucsd.edu 


In rec.ham-radio.packet, koning@koning.enet.dec.com (Paul Koning) writes: 


> 

> 

> 

> Sure, CSMA requires/assumes you hear the other participants. That's why 

> packet radio only faintly (at best) resembles CSMA: often you can't hear 

> other participants, and/or you hear non-participants. The use of beams 

> aggrevates the former problem, while helping the latter. Which one is the 
> bigger effect is likely to vary. 

> 
> 
> 


To put it bluntly, how much MORE broken could it get when you use beams? 
Ox when you don't, for that matter? 


CSMA is not an efficient architecture to implement over a divergent 

( radio ) environment. It indeed is "broken" when applied to radio. 
Multiple Access does not coexist with efficient information (energy) 
transfer in a radio environment. This is one of the points I attempted 
to make in my paper in the 9th ARRL Computer Networking Conference 
proceedings. 


However, if we are to exchange a large amount of information among a 
large number of users over a wide area we xmust* use directed beams. 
Fortunately for amateur radio the fact that CSMA doesn't suit a network 
of directed beams doesn't preclude other solutions. 

For a comparison of a network of omni with one of directed beams and 
some practical implications in an amateur radio environment please see 
the paper. 


73 
Glenn Elmore négn 


Date: 31 Jan 91 04:35:18 GMT 

From: snorkelwacker.mit.edu!usc!cs.utexas.edu!uwm.edu!rpi!clarkson! @bloom- 
beacon.mit.edu (Tadd, KA2DEW, ,3152621123) 

Subject: Omni vs beam antennas. 

To: packet-radio@ucsd.edu 


Date: 31 Jan 91 01:46:44 GMT 

From: usenet.ins.cwru.edu!ncoast!allbery@g.ms.uky.edu (Brandon S. Allbery KB8JRR) 
Subject: Omni vs beam antennas. 

To: packet-radio@ucsd.edu 


As quoted from <1991Jan28.223338.2863477@locus.com> by dana@locus.com (Dana H. 
Myers): 


If a topology was in use where a central node was serving a number 
of remotely located nodes, and these nodes could not hear each other 
anyway, and the remote nodes have poor signals into the central node, then 
using beams at the remote nodes would probably make sense, though the 
efficiency of this topology would never be as good as a completely 
interconnected topology. 


This is xexactlyx the situation on 144.99 in NE Ohio; we have one central site 
in Chardon, a few of us in Mentor and Painesville, and two outlying nodes (one 
in the southern part of Geauga County and one near Youngstown). The Chardon 
node used a beam for a few months, then was switched to an omni. 


In our particular case, the omni improved things for the Mentor and 
Painesville nodes but didn't lose the "DX" nodes: we (M/P) were working the 
back of the beam, which was aimed at the distant nodes, and packets from the 
northern end got lost quite often. The DX nodes are still in the network 


because they both have beams pointed at Chardon. 


In this particular case, complete interconnection is rather difficult --- as 
an example, I live in an apartment, which limits the height of antennas I can 
put up (it's a real coup that I was permitted my Ringo at 25ft.!), but the two 
remote nodes would require me to put up an antenna high enough to go over a 
freeway overpass and a Finast superstore, respectively. :-( The other M/P 
nodes have similar problems, and the DX nodes would have to drill signals 
through hills to get to anything other than the Chardon node. In this 
particular case, therefore, beams are a win for the distant nodes but a loss 
for the local ones. 


++Brandon 

Me: Brandon S. Allbery VHF/UHF: KB8IRR on 220, 2m, 440 
Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN 
America OnLine: KB8JRR AMPR: KB8IRR.AmPR.ORG [44.70.4.88] 
uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY 


Date: 31 Jan 91 06:20:54 GMT 

From: julius.cs.uiuc.edu!rpi!uwm.edu!spool.mu.edu!sdd.hp.com!hp-pcd!hp-vcd! 
carlp@apple.com (Carl Peterson) 

Subject: PACKET->Internet Gateway 

To: packet-radio@ucsd.edu 


Although I know of know gateway/routers for connecting from amateur 
TCP/IP or AX.25, I don't think that it would be very difficult to 
create on; especially given that many internet connected machines 
run Phil's TCP/IP code in preference to their original vendor 
supplied code. 


If you set up a gateway/router you would have to take a great 

deal of care about what addresses could access which services. 
Obviously, you could not allow a non 44. address to initiate 

a connection to a 44 address. This is doable. Within HP we 
restrict or gateways so that non-HP addresses cannot access our 
subnet. As the trustee of such a gateway I would be very nervious 
about someone making such a connection. I'd also be nervious 
about the type of traffic going across my gateway/router, but 

all amateur node operators suffer from that. The SMTP handler 
code would have to be configured to allow periodic trys to forward 
over several days before bouncing mail to account for most 
stations not being on the air at all times. The only real problem 
is registering the 44 address for routing purposes within internet. 
Couldn't we set up an open internet name/domain server for 44 
addresses across the country? 


I've been thinking about a more limited system for AX.25 traffic. 
Hosts could be set up for AX.25 which would act as a worm holes. 
The interface would be like any of the popular packet BBS systems, 
except that some of the nodes accessable would actually be similar 
systems in distantly located cities. The AX.25 packets would be 
completely encapsulated in standard TCP/IP. No access would be 
given to internet at large thus protecting the trustees of the 
nodes from problems about non-amateur access. One of the biggest 
frustrations I have with packet is not being able to connect '‘live' 
to friends in distant cities (no I don't have HF packet, and that's 
not very reliable). Think how this could substatually improve 

the throughput of mail and emergency messages (assuming that 
normal packet nodes are up and connect to an internet worm hole 
host that is up). 


Carl Peterson N6RZA 


Carl Peterson (206) 944-2745 
Hewlett-Packard | 
Vancouver Division (R&D Lab) | 
P.O. Box 8906 
Vancouver, WA 98668-8906 
HPDesk: Carl Peterson/HPD300/04 
Unix to Unix: carlp@hp-vcd.hp.com 

Syour path$!ucbvax!hplabs!hp-vcd!carlp 
or fyour path}!ucsd!hp-sdd!hp-vcd!carlp 
CompuServe: 71301,2532 


Date: 31 Jan 91 11:10:46 GMT 

From: mcsun!cernvax!frode@uunet.uu.net (frode weierud) 
Subject: Piccolo info. 

To: packet-radio@ucsd.edu 


I recently posted a reply to a few of the articles that 
delt with the multi-tone telegraphy system Piccolo. 
Unfortunately I think I forgot to specify the distribution 
and it was only posted locally so I will redistribute the 
earlier posting. Here comes ... 


There has recently been some interest in the British 
PICCOLO system and its French derivative COQUELET. 


PICCOLO was developed back in 1957 by a team lead by 

J.D. Ralphs at the Diplomatic Wireless Service, which 
today is called the Communication Engineering Department 
of the British Foreign and Commonwealth Office. The 
PICCOLO equipment has gone through several complete 
redesigns. The first equipment occupied a major part of 
a standard 19 inch rack, while today's unit, PICCOLO Mk 6, 
which is made by RACAL and is commercially available as 
LA 1117 is a rather small unit by comparison. 


PICCOLO is still in use by the British Foreign Office as 
its main HF communication mode and several frequencies 


are daily active for this purpose on HF bands. 


PICCOLO and its development has been described in detail 


in several publications, the first article appeared in 1963. 


1) H.K. Robin, D. Bayley, T.L. Murray and J.D. Ralphs, 
"Multitone signalling system employing quenched 
resonators for use on noisy radio-teleprinter 
circuits", Proceedings of I.E.E., Vol. 110, No. 9, 
September 1963, pp. 1554-1568. 


2) D. Bayley and J.D. Ralphs, 
"Piccolo 32-tone telegraph system in diplomatic 
communication", Proceedings of I.E.E., Vol. 119, No. 
September 1972, pp. 1229-1236. 


3) J.D. Ralphs, 
"The application of m.f£.s.k. techniques to h.f. 
telegraphy", The Radio and Electronic Engineer, 
Vol. 47, No. 10, October 1977, pp. 435-444. 


4) J.D. Ralphs, 
"An improved 'Piccolo' m.f.s.k. modem for h.f. 
telegraphy", The Radio and Electronic Engineer, 
Vol. 52, No. 7, July 1982, pp. 321-330. 


5) J.D. Ralphs, 
"Principles and practice of multi-frequency 
telegraphy", (book), Peter Pelegrinus on 
behalf of The Institute of Electrical Engineers, 
Peter Pelegrinus Ltd., London 1985, 
ISBN 0-86341-022-7. 


There have as well been a few non-technical articles on 
PICCOLO and COQUELET in Monitoring Times. 


9, 


6) Jack Albert, 
"Just When You Thought It Was Safe to Turn on the 
Radio", Monitoring Times, February 1989, page 47. 


7) Jack Albert, 
"U.S. Hobbyist First to Copy Piccolo", 
Monitoring Times, July 1989, page 47. 


8) Jack Albert, 
"Piccolog", Monitoring Times, August 1989, page 47. 


9) Jack Albert, 
"A New Piccolo System", (The French Coquelet System) 
Monitoring Times, March 1990, page 47. 


The only decoder available on the market that can decode 
both PICCOLO and COQUELET is CODE3 from HOKA Electronics, 
The Netherlands, equipped with the PICCOLO and COQUELET 
options. 


73 de Frode, LA2RL/HB9CHL 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKK 


* Frode Weierud Phone : AL 22 7674794 * 

* CERN, SL Fax :? 41 22 7823676 * 

* CH-1211 Geneva 23 E-mail : frode@cernvax.cern.ch 
* 

* Switzerland or weierud@cernvm.cern.ch 
x 
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Date: 31 Jan 91 03:06:51 GMT 

From: epic!karn@bellcore.com (Phil R. Karn) 
Subject: Problem with NET and another TSR 
To: packet-radio@ucsd.edu 


In article <19585@shlump.nac.dec.com>, gettys@regent.enet.dec.com (Bob 
Gettys N1BRM) writes: 

> 

>I'm having a problem wich I hope someone on the net can help with. I'm 
>running the KA9Q Internet Protocol Package, v890421.11.tl1 DS=7a57 with 
NET/ROM 

>support added by Dan Frank, WINK and Window support by Frank Knight, 
KALSYF. 


That is a *reallyx old version. 


>I'm also trying to run the WXDATA program for the Heath ID-5001 
weather 

>computer. They have a definite interaction that hurts only the KA9Q 
net 

>program. Without the WXDATA TSR running, the net program runs just 
fine. With 

>the WXDATA program running, the net program gets many bad checksum 
packets to 

>the point that communications is immpossible. 


Offhand, I suspect that your WXDATA TSR is taking over the machine 
with interrupts disabled for long periods of time, starving the 
interrupt handlers in NET that handle the serial port. This results in 
lost characters and corrupted packets. 


Your best bet is to a) upgrade to a recent version of NOS and b) 
replace your 8250 or 16450 serial chips with NS16550A chips. These 
chips provide 16-byte FIFO buffering on both transmit and receive 
which substantially reduces interrupt latency requirements; hopefully 
this will give you the margin you need to run WXDATA and NOS at the 
same time. 


NOS is required here because the 16550A chips require a little extra 
software to enable FIFO mode that is not in the old NET versions. 
However, 

the 16550As will work fine with your other communication programs, even 
those that don't know about them, because they come up in 8250 
compatibility 

mode by default. 


Phil 


Date: 30 Jan 91 21:02:18 GMT 

From: sdd.hp.com!samsung!rex!uflorida!mlb.semi.harris.com!trantor.harris-atd.com! 
x102c.ess.harris.com!gbastin@ucsd.edu (Gary Bastin 60293) 

Subject: Procomm Bug in Packet Use 

To: packet-radio@ucsd.edu 


In the process of debugging a packet AX.25 LAN, an obscure bug was 
discovered in Procomm Version 2.4.X, as well as Procomm Plus. 
Namely, if there is a busy channel, with collisions, the XON/XOFF 
function of Procomm doesn't work properly. Procomm, all versions, 
has a built-in timer of ~20 seconds that times the duration from 


the last XOFF. If, within this 20 seconds, XON is not performed, 
then after 20 seconds, Procomm assumes that a noise burst caused 
the XOFF. Data is then dumped anyway. For the case of sending a 
file, and if collisions occur, then the tnc may not be ready to 
receive more data within 20 seconds. If this is the case, then 
the tnc buffer is overflowed! This was the case on a military 
AX.25 LAN! 


As for the fix, Datastorm Technology has a patch program called 
DT_PATCH which can patch the Procomm Plus executible to set the 
timer from 20 seconds up to 18 hours. As received out of the box, 
though, Procomm Plus has the 20 second feature/bug. The patch 
program must be run to fix the problem. No patches exist for the 
older shareware versions 2.4.X, and Datastorm plans no future 
patches to these versions. Fortunately, an upgrade from the 
shareware versions 2.4.X to the new Procomm Plus is available for 
$39.00. This is better than the full retail price of $119. 


Hopefully, knowledge of this feature/bug in Procomm, all versions, 
may save someone else some grief! 73, Gary 


Gary Bastin, WB4YAF /-/-/ Internet: gbastin@x102c.ess.harris.com 
Mail Stop 102-4826 | phone: (407) 729-3045 

Harris Corporation GASD | 

P.O.B. 94000, Melbourne FL 32902 Speaking from, but not for, Harris! 


Date: 31 Jan 91 04:40:34 GMT 

From: sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu! 
matt.ksu.ksu.edu!steve@ucsd.edu (Steve Schallehn) 

Subject: Shareware on Packet 

To: packet-radio@ucsd.edu 


A question was posed to me by an amateur who is interested in getting 
into packet. It seems he has a large collection of shareware on his 
land-line BBS and he was wondering if he could legally set up his 

BBS on packet and allow shareware downloads. 


I know about the avoiding business in amateur radio, but does 
shareware count? 


-Steve Schallehn, KBOAGD 
Kansas State University 


Date: 31 Jan 91 04:56:22 GMT 

From: maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@uunet.uu.net (Steve Schallehn) 
Subject: TCP/IP over long distances 

To: packet-radio@ucsd.edu 


In the last issue of QEX magazine, the "Gateway" had a listing 
of finger and mail services for TCP/IP. A question popped into my 
head as why such a list was given in a national magazine. 


Since we do not have a nationwide TCP/IP network in the USA, is 
connectivity to these services a problem or is it 
possible for ANY TCP/IP'er to use these services. 


-Steve Schallehn, KBOAGD 
Kansas State University 


PS: I just got my IP address and I don't have anyone to talk to! :-( 


Date: 31 Jan 91 05:28:20 GMT 

From: usc!ucselx!petunia!csuchico.edu!warlock@ucsd.edu (John Kennedy) 
Subject: Trolling for suggestions 

To: packet-radio@ucsd.edu 


How is this for getting my feet wet? 


I've just got my license (sent in the paperwork near Xmas, got the license 
today -- KC6RCK). What I'm looking to do is latch a packet radio onto a UNIX 
machine. The goal is to get all the advantages of packet TCP/IP without 
actually having to resort to an IBM. (-: 


I do have the UNIX machine. I've yet to get the transceiver, but I'm 
thinking about a Kantronics KAM (lots of goodies to use, some overkill, but 
a few that I'd like to take advantage of eventually, with a bay for an extra 
modem). Then it's off to scrounge for the rest. 


If anybody's already done this, I'd be interested in hearing from them, as 
well as any commonts from other people. 


Warlock, AKA hein aes Seo Sia erie Sere oe oS Se + 
John Kennedy internet: warlock@ecst.csuchico.edu 
| 
CSU Chico SEIS ite ay hee eae each aan re ia Bein rose Beer + 


KC6RCK IBM, You BM, We All BM for IBM! 


Date: (null) 
From: (null) 
Pete, 

Using omni directional antennas would only be better if it was your 
intention to have all of the stations on the frequency able to hear 
each other. That means that there could only be one LAN on the frequency 
in your whole region. This might be greedy, depending on where you were. 

Using beams puts you in a classic hidden transmitter syndrome situation. 
One of the solutions to that situation occurs when there is only one 
station that does 95% of the transmitting. In that case all you must make 
sure of is that the one station is heard by everybody else. Thus the beams. 
In that senario the one station is -more or less- controlling the 
frequency. It actually works. What you have to do is keep the other 
stations from transmitting alot of data. 

One application of this is where a BBS has it's user access port ona 
2m channel. The users access the BBS on that channel and perhaps route 
through the BBS using the G8BPQ driver to the network. THe BBS MUST do 
its forwarding and network linking on another, non-interfering frequency. 

Tadd - KA2DEW 


[ North East Digital Association - Editor Tadd Torborg ] 
[ Clarkson University, Potsdam NY Box 330 ] 
[ torbortc@clutx.clarkson.edu Colton NY ] 
[ 315-262-1123 ] 
[ Remember, if you win the rat race, you're still a rat ] 


End of Packet-Radio Digest 
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